In mobile networks, mobile nodes (MNs) can request dynamic home IP address assignment, based on their Network Access Identifiers (NAIs). The IP address is assigned by one of three entities, a home agent (HA), an Authorization, Authentication, Accounting (AAA) server, or a Dynamic Host Control Protocol (DHCP) server. When a new MN registers and is assigned an IP address, a routing entry is created in the routing/forwarding table in order to assign the appropriate route for any packets destined to the MN. When a MN leaves (deregisters/expires), the associated home IP address is released and the routing entry is removed from the routing/forwarding table. The routing entry points to an outgoing/destination interface, controlled by the HA, to which packets are sent.
As the number of MNs can be quite large (e.g., on the order of millions), the size of the routing/forwarding table can become unmanageably large if each route for each MN is stored individually. Additionally, the number of routing entries that can be stored on a per-interface basis is limited by the total amount of memory available. One technique used to mitigate such problems is to perform address aggregation on routing/forwarding tables for each destination interface. In this technique, only MNs that are registered (or permitted) are allowed to be represented in the routing/forwarding tables (i.e., no routes should be present for any MN that is not registered/permitted. Disadvantageously, however, due to the dynamic nature of the network (with MNs joining/leaving the network), address aggregation can become unwieldy because the address server assigns IP addresses to joining MNs sequentially while continuing to withdraw IP address from leaving MNs, resulting in a large number of holes in the IP address space available at the address server.
The problems of existing address aggregation can be seen from an example. As an example, assume that eight MNs join the network and are assigned IP addresses 10.1.2.0-10.1.2.7, which, using address aggregation, results in one routing table entry of 10.1.2.0/29. In this example, assuming that the MN assigned IP address 10.1.2.4 leaves the network, the routing table will need three routing entries to support the seven remaining MNs (i.e., 10.1.2.0/30, 10.1.2.6/31, 10.1.2.5/32). In this example, if another MN then joins the network, if a next sequential IP address is assigned (i.e., 10.1.2.9), the routing table will then need four entries to support eight MNs (i.e., the previous three, plus 10.1.2.9/32). Thus, from this example it may be seen that existing address aggregation schemes perform sub-optimally. The problem is worse in real networks which support a much larger numbers of MNs.